1. Field of the Invention
The present invention generally relates to the estimation of path delays in a telecommunication network, in order to synchronize distributed clocks.
2. Description of the Prior Art
The Precision Time Protocol (PTP) is a standardized protocol used to synchronize clocks throughout a communication network. In 2008 a revised standard, IEEE 1588-2008, was released. This new version is also known as protocol PTPv2.
The operation of PTP relies on measurements of the communication path delay between a time source, referred to as a master, and a given time receiver, referred to as a slave. This process involves a message transaction between the master and the slave where the precise instants of transmission and reception are measured/captured—preferably at the hardware level. Messages containing captured time information could be adjusted to account for their path delay, therefore providing a more accurate representation of the time information conveyed.
The IEEE 1588-2008 standard describes hierarchical master-slave architecture for clock distribution. Under this architecture, a time distribution system consists of one or more communication media (network segments), and one or more clocks.
An ordinary clock is a device with a single PTP port and is either a source (master) or a destination (slave) of the synchronization distribution chain.
A boundary clock has multiple PTP ports and can accurately bridge synchronization network segments distributing the time reference from one network segment to another. A synchronization master is elected, as the relative time reference, for each of the network segments in the system. The absolute time reference is represented by the grandmaster. The grandmaster transmits synchronization information to clocks residing within its assign network domain/segment. Boundary clocks located on that network segment, recover the absolute time reference as accurately as possible, then distribute the recovered time reference to downstream network segments to which they are also connected.
The grandmaster clock represents the absolute time source. The grandmaster, the boundary clocks and the (ordinary) slave clocks are organized into a tree-like hierarchy with the grandmaster as the root of this hierarchy, the slave clocks as its leaves, and boundary clocks as intermediate elements. The grandmaster distributes the time reference towards the slave clocks across this tree-like hierarchy. The synchronization path between the grandmaster and a given slave clock can be decomposed as a succession of pairs of master and slave with the slave of the upstream segment becoming the master of the downstream segment. Between a given pair of the aforementioned master and slave are deployed transparent clocks.
IEEE 1588-2008 introduces a so called transparent clock associated with a network equipment used to convey PTP messages. A transparent clock modifies PTP message (headers) as these messages cross the network device. The transparent clock process consists in measuring the PTP message residence time within the network equipment and cumulate this measure in a field, located in the PTP message header, called the correctionField. This methodology improves the synchronization distribution accuracy by compensating for residence time variability across a network equipment.
There are two types of transparent clocks:                End-w-end transparent clocks measure and update the residence time for each synchronization packet (e.g. Synch message).        Peer-to-peer transparent docks perform similar operations as the end-to-end transparent clock. In addition, they measure the link delay associated with the ingress transmission path (upstream communication path delineated by either a Peer to Peer transparent clock or a Master) and cumulate this delay in the correctionField as well.        
PTP delay measurement process of the path between any given pair of master and slave essentially involves the precision timing of two messages: A Sync message and a delay_Req message. Half of the round-trip delay obtained by the exchange of these two messages provides an estimation of the one-way (in the master to slave communication direction) delay. Accordingly, the accuracy of such estimation is generally impacted by two types of noises:                The first one is the Packet Delay Variation (PDV) which represents the variability of delays undergone by different synchronization packets on a given synchronization path. This variability makes that the estimated path delay associated to a synchronization message is noisy due to the difference in time between the path delay estimation event and the actual message transmission event.        The second type of noise is the delay asymmetry which represents the difference of path delays between one way of communication with regards to the opposite one. The slave time offset inaccuracy is theoretically equal to half of the delay asymmetry.        
The PTPv2 protocol provides transparent clocks in order to address the aforementioned noises impacting the accuracy of the synchronization distribution.
Transparent clocks essentially measure synchronization message residence time within the associated network equipment. The measured residence times are cumulated in the correctionField located within the synchronization packet header. For stringent synchronization requirements, transparent clocks must perform all those operations very accurately and on the fly (at the PTPV2 message rate) without introducing additional delays.
Transparent clocks are generally deployed between a given pair of master and slave clocks in order to measure the synchronization message residence times across traversed network nodes. The sum of all measured residence times is taken off the end-to-end path delay by the slave (or the master). This makes nodes implementing transparent clocks “transparent” to the slave (or the master) in term of end-to-end path delay budget.
Within the IEEE 1588_2008 standard, the peer delay mechanism is also introduced for estimating delays of paths between adjacent transparent clocks, or between a transparent clock and the direct (i.e. adjacent) master or direct (i.e. adjacent) slave. Those measured path delays, as well as delay asymmetries, are cumulated within the Sync message correctionField by the peer-to-peer transparent clocks, so that the slave clock can be informed of them in addition to traversed network node residence times. With all this information, a slave can more precisely compute its offset with regards to the master clock time scale, as this computation is less noisy with regards to packet delay variation and delay asymmetry.
FIG. 1 illustrates the basic peer delay method in an exemplary part of a network comprising two IP routers IPRA and IPRB, each comprising a peer-to-peer (P2P) transparent clock (P2PTCA and P2PTCB) and at least two Precision Time Protocol (PTP) ports. For instance the IP router IPRA comprises two PTP ports PA1 and PA2; the IP router IPRB comprises two PTP ports PB1 and PB2. The PTP port PA1 of the router IPRA is directly linked (i.e. no intermediate network nodes) to the PTP port PB1 of the router IPRB.
The router IPRB sends a Pdelay_Req message to the router IPRA. The latter replies with a Pdelay_Resp message. The router IPRB then estimates the path delay induced by the link between the router IPRA and the router IPRB.
Later, the router IPRA receives a Synch message SYNC originating from a master clock and going at least to one slave clock, via the routers IPRA and IPRB. This message brings synchronization information to the slave.
With regards to FIG. 1 topology, there is no problem to associate the estimated path delay (or link delay) to the Sync message, because there is only one possible path. The peer-to-peer transparent clock PTPTCB of router IPRB updates the correctionField by taking into account the estimated path delay between the router IPRA and the router IPRB.
However, there are concerns within PTPv2 standard on the deployment of the peer delay mechanism, especially when peer delay entities are not directly linked, meaning that they are separated by at least one intermediate node (If the later is a network node that does not support PTPv2, or if it is a network node that comprises an end-to-end transparent clock);
For the rest of the description, we refer to this type of deployment as “non link-by-link” deployment of the peer delay mechanism.
It is noted that a peer-to-peer transparent clock and the associated network node perform very different specific operations. Thus, the peer-to-peer transparent clock only performs modifications over PTP message (headers) while the associated network is responsible for the encapsulation and the forwarding of the PTP messages.
For the rest of the document and for all the performed operations, the mention to the peer-to-peer transparent clock and the mention to the associated network node are interchangeable, as per the sake of simplicity.
Clause 11.4.4 of the IEEE 1588_2008 standard describes the peer delay mechanism concern as following:
“A delay requestor, Node-A, may receive 0, 1, or multiple Pdelay_Resp messages for each transmitted Pdelay_Req. Multiple responses can be detected by observing that the Source Port Identity fields of the Pdelay_Resp messages differ.
NOTE: Multiple responses can occur if there is an end-to-end transparent clock or an ordinary bridge or other similar multicast and multiport devices between Node-A and multiple Node-B devices. Although the multiple responses can be distinguished, there is no mechanism in this standard that allows the path length associated with each of the responses from the multiple Node-B devices to be correctly assigned to a received Sync message.”
As described by the aforementioned clause, the concern is that there is no mechanism defined within PTPv2 standard to allow the receiver of a Sync message to associate the right path delay to this message, amongst different measured path delays (i.e. estimated via the peer delay mechanism). This concern essentially focuses on the multicast scenario. However, the standard concern can be generalized to include the unicast scenario as well.
FIGS. 2, 3, 4 illustrate the issue with path delay association in an exemplary part of a network comprising three IP routers IPRA, IPRB, IPRC, and an intermediate router IPRI. Each IP router IPRA, IPRB, IPRC comprises each a peer-to-peer transparent clock, respectively P2P TC A, P2P TC B, P2P TC C. Each IP routers IPRA and IPRB comprises at least two PTP ports, especially with PTP port PA on P2P TC A and PB on P2P TC B, having respectively IP addresses @IP-A and @IP-B.
The router IPRC comprises three PTP ports and especially PC1, PC2, both corresponding to a same IP address @IP-C. It is noted here that PTPv2 standard does not forbid the implementation of several PTP ports over the same network interface or communication port.
The intermediate IP router IPRI comprises three communication ports (i.e. IP ports).
The PTP port PA of the router IPRA is directly linked to a first IP port of the intermediate router IPRI. The IP port associated to PTP port PB of the router IPRB is directly linked to a second IP port of the intermediate router IPRI. The IP port associated to PTP port PC of the router IPRC is directly linked to a third IP port of the intermediate router IPRI.
The peer-to-peer transparent clock P2P TC C of router IPRC has two peers, respectively the peer-to-peer transparent clock P2P T CA in router IPRA, and the peer-to-peer transparent clock P2P TC B in router IPRB. There is no PTP clock in the intermediate IP router IPRI. This router is called a non-PTP aware equipment.
FIG. 2 illustrates the issue with the path delay association in a unicast scenario, and a network topology where the intermediate router IPRI is a non-PTP aware network element because it does not comprise a transparent clock. The peer-to-peer mechanism is deployed to measure the path delay between pairs of adjacent peer-to-peer transparent clocks:                P2P TC A and P2P TC C for a first path.        P2P TC B and P2P TC C for a second path.        
The peer-to-peer transparent clocks P2P TC A and P2P TC B implement respectively two PTP ports corresponding to the addresses @IP-A and @IP-B. In this deployment of the peer delay mechanism, the peer-to-peer transparent clock P2P TC C implements two different PTP ports PC1 and PC2 over a same IP port corresponding to the address @IP-C. This is possible as not forbidden by the PTPv2 standard. Thus, the peer-to-peer transparent clock P2P TC C of router IPRC has the knowledge of two path delays, respectively the one between itself and peer-to-peer transparent clock P2P TC A and the one between itself and the peer-to-peer transparent clock P2P TC B.
Within the network topology and deployment as illustrated by FIG. 2, the peer-to-peer transparent clock P2P TC C has an issue to identify the path followed by the Sync message at the reception of the later. Indeed, neither the source (PTP) port identity nor the source IP address of the Sync message allows the clock P2P TC C to know whether the message has transited via the clock P2P TC A or via the clock P2P TC B, as the aforementioned pieces of information are those related to the far end master clock (not represented in the FIG. 2).
It is noted that FIG. 2 illustrates a specific case with two PTP ports PC1 and PC2 implemented on a same IP port of the router IPRC, this IP port corresponding to the address @IP-C. This is only for the sake of description simplicity. However, the issue can be generalized to cases where each PTP port is associated to one transport protocol related port (e.g. IP port).
The issue cannot be resolved using only the PTPv2 protocol. Thus, the IEEE 1588_2008 standard presently provides with recommendations to restrict the use of peer delay mechanisms. This precludes, for instance, the deployment of a mix of end-to-end transparent clocks and peer-to-peer transparent clocks, or a mix of non-PTP aware network elements and peer-to-peer-transparent clocks, in order to optimize the deployment costs and also to relax deployment constraints.
FIG. 3 illustrates the issue with path delay association in another network topology that is restricted (or avoided) by the standard. The topology is the same as the one of FIG. 2 except that the intermediate router IPRI′ comprises an end-to-end transparent clock E2E TC I. The peer-to-peer transparent clock P2P TC C of the router IPRC implements two PTP ports PC1 and PC2 on a same IP port corresponding to the address @IP-C.
The peer-to-peer mechanism is deployed to measure path delays between pairs of adjacent peer-to-peer transparent clocks:                P2P TC A and P2P TC C for a first path.        P2P TC B and P2P TC C for a second path.        
This deployment is restricted (or avoided) by the standard as there is no means to associate to the Sync message the right path delay as explained above. The operator of the network should deploy in this case a link-by-link peer delay mechanism as illustrated by the FIG. 4.
Stressing on the advantage of the invention, FIG. 4 illustrates the path delay association in a deployment that is allowed by the standard. The topology is the same as the one of FIG. 2 except that the intermediate router IPRI′ comprises a peer-to-peer transparent clock P2P TC I; and the peer-to-peer transparent clock P2P TC C of the router IPRC implements a single PTP port PC on an IP port corresponding to the address @IP-C.
In this deployment, the peer delay mechanism is deployed:                On the link between the peer-to-peer transparent clock P2P TC A of the router IPRA and the peer-to-peer transparent clock P2P TC I of the intermediate router IPRI′.        On the link between the peer-to-peer transparent clock P2P TC B of the router IPRB and the peer-to-peer transparent clock P2P TC I of the intermediate router IPRI′.        On the link between the peer-to-peer transparent clock P2P TC C of the router IPRC and the peer-to-peer transparent clock P2P TC I of the intermediate router IPRI′.        
The later implementation is not cost effective especially when there is a mesh network, i. e. as per deployment of a great number of peer delay mechanisms, this number being equal to N×(N−1) where N is the number of network nodes.
Thus, there is a need to provide a more cost effective technical solution for supporting the peer delay mechanism.
This can be solved by applying the method according to the invention.